Please forgive the pseudo-Victoriana opening -- just my way of saying that this article is going to be an inch thick and a mile wide. I want to discuss the following issues; bugs and debugging, organisation and support of other E coders, the E mailing list, the effect of the weather on my code, the random nature of computer problems, the future of the Amiga, Bill Gates' plans for world domination, the current situation in Bosnia, and anything else that I can reasonably drag in without it seeming too forced. [grin]
Oh, and I'll also include an interesting code snippet. I can't really take credit for writing this one - it's a translation from C, the 'term' source by Olaf Barthel, to be precise. It enables Workbench-launched programs to clone the Workbench path list. This is very handy for programs like the compiler frontend that I am writing - it means you don't need to specify the full path for everything within the settings of the program itself. If you're actually reading this column just to see what code tips you can glean from the pearls of wisdom I cast before you all, you may as well go directly here or here.
I was working on the ultimate file handling module to present to you all, but time constraints intervened -- maybe next month, if I get the time. Writing the code isn't a problem, but checking it in enough situations that I won't look foolish when I publish it takes more time than I'd prefer, especially with the weather as it is here.
Anyway, read on, enjoy the show, get what you can out of it and write to me if you want to comment on anything...
Why is that my ability to write decent, legible code goes out the window when the temperature tops 30° C? I've been looking across some of the code I've written in the last fortnight or so and, despite the comments I leave scattered through it, I still can't make any sense of it.
One of the things I've noticed is that, now that I've reached a reasonable level of competency in programming, is that I don't make errors based on an inadequate understanding of the OS or the language design. No, now I know how to approach the more difficult topics. The mistakes I do make are the glaringly obvious ones that I don't pick up because my brain is working on a much more abstracted and rarefied level. I'm not sure whether this is a good or a bad thing, but it's extremely frustrating :@.
One thing that I think the E programming community needs is some focal point to organise around. A venue to congregate, projects to work on together, a place to store tips, tricks and code examples, somewhere a little more conducive to interaction than the 'dev/e' directory on Aminet.
The E Encyclopedia looked like a good place when it opened, but that was many months ago and nothing on the site seems to have changed since :(. I mailed the people who were working on it, but never received a reply...
I think that we need a similar organis(m|ation) to serve a number of purposes; both archival and supporting future growth, as a central clearing-house for ideas about the direction of the language, or for code modules that people want others to write, or even for feedback to authors on their programs. I am sure that there are many other needs that could also be served by such a (web site/mailing list/... whatever) Because news service with my (cheap) ISP is pretty bad and comp.sys.amiga.programmer is always at least three months out of date, I feel isolated from what is probably the main meeting-place for Amiga programmers.
Contact me on the address above if you want to discuss this further, or talk about starting something up; I'll do something about this only if I am convinced that the facility would actually be of use to other people.
There used to be the E mailing list, but...
I've tried mailing the E mailing list request address a number of times. My mails never get returned, so they seem to be ending up in some Internet equivalent of the dead letter office.... caught in e-mail limbo. Now, I've been trying to work out exactly what's happened to the list, and I came up with the following possibilities:
If anyone can help me discover what's happened, it would be muchly appreciated. If the list has stopped, maybe we could kickstart an effort for a new one, or organise a similar means of communication (private newsgroups or somesuch).
Anyway, raving over, onwards to more serious matters...
Before you look at this, a warning -- it works for me, but I am not 100% sure of the intricate details of C-to-E translation... so consider it a pretty good first try. Complaints on a postcard to the usual address, please...
The code for the module itself can be reached by clicking on
this word.
There is only one PROC exported - that is attachCLI(),
which takes one argument; a pointer to the Workbench startup message. I usually call
it in the following manner:
MODULE '*fixpath', 'workbench/startup'
PROC main()
DEF su:PTR TO wbstartup
-> have we run from WB or CLI?
IF (su:=wbmessage)<>NIL
/* Get other info from the wbmessage */
attachCLI(su)
ELSE
/* do CLI specific stuff... */
ENDIF
/* etc......*/
ENDPROC
wbmessage is, of course, a builtin variable, part of the E spec,
that contains a pointer to the Workbench startup message. You could integrate the
check for the Workbench startup into the module itself, but I prefer to make it
a part of the main program, as other details (like the name of the program, and so
on) can be obtained from wbmessage as well.
PRIVATE parts
When constructing objects in modules, one of the problems with
EXPORTing the object is that all of the methods
of the object are able to be accessed by the casual user. For
example, if you set up an object like this:
OBJECT example
sigbit
PRIVATE
internals
ENDOBJECT
PROC public_init() OF example
-> blah blah blah....
ENDPROC
PROC private_a(complex_variable) OF example IS self.private_b(100, complex_variable)
PROC private_b(x, y) OF example
-> more blah blah...
ENDPROC
then ShowModule will give you an output something like this...
(----) OBJECT example
( 4) sigbit:LONG
public_init()
private_a(a)
private_b(a, b)
(----) ENDOBJECT /* SIZEOF=12 */
when you most certainly don't want the last two procedures to
be open to the public. Maybe in a future version of E Wouter can add
an extra command to handle this, or extend the range of the
PRIVATE operator to cover methods as well;
I would like to define a method which was private to an object like this:
PROC private_b(x, y) OF example PRIVATE
-> more blah blah...
ENDPROC
but this is sadly not possible at the moment.
For now, the fix is revert to a little bit of standard (i.e. non object-oriented) code. If the last two procedures are defined as follows:
PROC private_a(ex:PTR TO example, complex_variable) IS private_b(ex, 100, complex_variable)
PROC private_b(ex:PTR TO example, x, y)
-> more blah blah...
ENDPROC
(and, of course, OPT EXPORT is not enabled)
then the private procedures will remain truly private. This is
something of a kludgey approach to something that could easily
be handled in the language implementation; we can only hope that
this will be changed in the future.
Don't go! Go back to the top and read it all again!
OK, I understand. You've got better things to do than sit around in front of your computer. Until next time, then...